In the area of enterprise applications based on JAVA Enterprise Edition (JEE), it is common practice to use the JAVA Remote Method Invocation (RMI) protocol, when a client (or a client application) intends to converse with a server (or multiple server instances). JAVA RMI is an enterprise technology, well entrenched in the enterprise information technology (IT) software industry.
The JAVA RMI protocol is based on the Common Object Request Broker Architecture (CORBA), and in most cases it will use its Internet Inter-ORB Protocol (IIOP) to marshal JAVA objects between a client and a server instance using a Transmission Control Protocol (TCP)/Internet Protocol (IP) connection.
However popular it is, JAVA RMI also poses limitations. In particular, client applications cannot achieve load-balancing without addressing it specifically in their code. However, in most cases where load-balancing is required, a customer (who owns the client and server applications) does not have access to modify the client software, and in many cases does not even have the server code. That means, if the client software was not originally created to include load-balancing of specific server components/services, there is no external “off-the-shelf” solution available to change it.
In many cases, the customer—e.g. an enterprise company that uses IT systems to manage its business processes—does not possess the skill, the manpower and/or the requirements to modify the systems. At the present, the customer must rely heavily on off-the-shelf, field-programmable equipment, in order to provide means to manage the likes of availability, scalability, resilience, load balancing, and so on and so forth.
The typical prior art JEE RMI flow in a typical prior art system 500 is depicted in FIG. 5, and contains internal software facilities to manage load balancing. However, unless all the software application components adhere to strict rules and design patterns, these internal facilities become a hindrance, and prohibit load-balancing by external means (like load-balancing appliances and application-delivery controllers).
The way JEE RMI is designed in the prior art, the only connection that can be externally load-balanced is the initial call (e.g. a remote JAVA application object request) of a client 501 to a JAVA Naming and Directory Interface (JNDI) component 505. After the initial call, an Interoperable Object Reference (IOR) is returned to the client 501, which causes the client 501 to bypass any load-balancer. In a JEE cluster architecture several server instances 502 of the JEE server/container may exist, each with its own JNDI instance 505. The JNDI instances 505 are all connected, and coordinate the allocation of an EJB Home 506 on one of the server instances 502 (i.e. provide internal load-balancing).
The classic approach of a JEE client-server reaction model is that every service call (e.g. every remote JAVA application method invocation request) that a client 501 sends to the server instances 502 is an entirely new EJB request. When done like this, each new EJB request will be handled by the internal load-balancing mechanism. This approach is extremely wasteful in system resources, and yields poor performance and user experience, especially when the user-base of the system grows, or when additional branches are added to the business, which need to communicate with the “central office”, i.e. the client 501 and server instances 502 become physically more distant with noticeable latency.
In order to overcome the wastefulness of creating new objects for each remote JAVA application method invocation request, the client application needs to actively participate in the load-balancing, e.g. by requesting many IORs from the server instances 502 “in advance” (i.e. creating a pool of objects), and then to run on them in some load-balanced manner (e.g. using round-robin). However, this approach requires that the client software is designed in a certain way, and it is not possible to impose this solution on to existing client software.
Attempts at resolving this problem have been tried by many companies for many years with limited success. Most notably, JEE Application Server vendors created proprietary software solutions that run as a gateway between client 501 calls and the server instances 502, and carry out load-balancing. However, these solutions are hard to configure, maintain, and operate, and have terrible performance impact. Moreover, said solutions are expensive, because additional processing power and software licenses are needed. These solutions can also not be considered “production-grade”, in terms of reliability.
Other workarounds move from JEE to Hypertext Transfer Protocol (HTTP) communication between client and server instances, which can easily be load-balanced. This approach, however, comes with its own set of drawbacks, such as a much slower and byte-heavy communication (especially notable when the client and server instances are separated by a Wide-Area Network (WAN)), as well as computational overhead, which is expressed in additional resources, power and latency, both on the client and the server side.